Casting is a technique for using one computing device to control what media content is displayed by another computing device. Commonly, a mobile phone is used to cast media content to a TV. The term “casting” is used generally to refer to two different techniques: (1) rendering content (or otherwise obtaining rendered content) on a computing device (e.g., a phone) and then outputting the rendered content for display on the other computing device (e.g., a cast-enabled TV or a TV to which a cast device has been connected); and (2) sending instructions to the other computing device for retrieving the content directly from the source.
FIGS. 1A and 1B generally illustrate these two techniques. In FIG. 1A, a client 101 is shown as sending rendered content to cast device 102. Client 101 can represent any type of computing device that is capable of casting to another device. For example, client 101 can represent a smart phone, a laptop or desktop computer, etc. Cast device 102 would typically represent a TV to which a cast device (e.g., a Chromecast device) has been connected. However, many TVs are currently being manufactured with built-in casting capabilities. In either case, client 101 and cast device 102 can be connected to the same LAN (or more particularly, the same subnet) to allow the content rendered by client 101 to be transmitted to cast device 102 for display. This technique is oftentimes called screen mirroring since the rendered content sent to the cast device is typically the same as the rendered content that is displayed locally on the client. However, this technique may also be employed to output rendered content that will not be displayed locally. For example, Google provides a “Remote Display” API which allows game developers to output a game's main display on a TV while simultaneously outputting an auxiliary display on the local device.
FIG. 1B illustrates the second general type of casting. In this case, client 101 sends an identification of content to retrieve, e.g., in the form of a URL, to cast device 102. Cast device 102 then retrieves the content directly from the content source 103 and renders it for display. Casting a YouTube video is a common example of this second type of casting. In addition to identifying the content to retrieve, client 101 can also provide playback controls while the content is being displayed. For example, client 101 may instruct cast device 102 to pause, skip forward, of terminate playback.
A key requirement of these casting techniques is that client 101 and cast device 102 must be part of the same subnet (or may possibly connect using Wi-Fi direct). This presents various difficulties in a desktop virtualization environment. In such environments, client 101 employs a remote display protocol to receive desktop display data for a remote desktop that is executing on a server (i.e., a computing device that is likely not part of the same subnet). In such a case, if it is desired to cast the remote desktop to cast device 102, the only option would be to render the remote desktop on client 101 and then use the first type of casting to transfer the rendered desktop to cast device 102. More specifically, client 101 would need a screen mirroring application that could capture the display buffer of client 101 and send it to cast device 102. The same would be true in published application scenarios (i.e., in scenarios where the display data for a single application rather than the entire desktop is sent to client 101).
The second type of casting would not be available because the server is not part of the same subnet as cast device 102. Therefore, cast device 102 would not be visible to the server. Because only the screen mirroring type of casting would be available in desktop virtualization environments, the casting experience will oftentimes be diminished for a number of reasons. For example, a significant amount of processing is required to decode the desktop display data, display it locally, and then transmit the display buffer contents to cast device 102. If client 101 is running on a battery (e.g., a laptop or smart phone), this processing can quickly drain it. Also, the remote display protocol oftentimes imposes limitations on the video quality such as by limiting the frame rate to 30 fps in a best case scenario. Furthermore, in practice, the frame rate at which desktop display data is transmitted via the remote display protocol is oftentimes much less due to network bandwidth or other limitations. In short, employing screen mirroring to cast a remote desktop to another display oftentimes results in a suboptimal experience.